<?php
/**
 * <https://y.st./>
 * Copyright © 2018 Alex Yst <mailto:copyright@y.st>
 * 
 * This program is free software: you can redistribute it and/or modify
 * it under the terms of the GNU General Public License as published by
 * the Free Software Foundation, either version 3 of the License, or
 * (at your option) any later version.
 * 
 * This program is distributed in the hope that it will be useful,
 * but WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
 * GNU General Public License for more details.
 * 
 * You should have received a copy of the GNU General Public License
 * along with this program. If not, see <https://www.gnu.org./licenses/>.
**/

$xhtml = array(
	'<{title}>' => $a['UDP'],
	'<{subtitle}>' => 'Written in <span title="Communications and Networking">CS 2204</span> by <a href="https://y.st./">Alex Yst</a>, finalised on 2018-05-23',
	'<{copyright year}>' => '2018',
	'takedown' => '2017-11-01',
	'<{body}>' => <<<END
<h2>Fragmentation</h2>
<p>
	According to $a[RFC] 791, $a[IP] packets may be fragmented, but the data contained in the payload can only be split on an eight-byte (sixty-four-bit) boundary (Information Sciences Institute, 1981).
	Headers from the initial packet are duplicated and included in all fragments, and sequence numbers (for reassembly) are added along with an identification field (to distinguish fragments of this packet from fragments of another).
</p>
<p>
	$a[UDP] headers are eight bytes long (Dordal, 2014), and are part of the payload data as seen by $a[IPv4].
	That makes our $a[IPv4] payload length 2008 bytes long.
	We&apos;re not given the size of the $a[IPv4] header used, and $a[IPv4] uses variable-width headers, unlike $a[IPv6].
	Ignoring $a[IPv4] headers, a minimum of two fragments should be necessary; including maximum size headers, only two fragments should be needed as well.
	We can thus assume that a well-written implementation will fragment this packet into only two parts, but this is not strictly required; as many as 251 (2008 divided by 8) fragments are in fact possible.
	$a[RFC] 791 also makes no specification about along what lines fragmentation must occur, beyond specifying that it must be on an eight-byte boundary, making it implementation-dependant.
	It&apos;s also worth noting that packet reassembly doesn&apos;t occur at the other end of the Ethernet link, but rather, at the original packet&apos;s destination.
</p>
<h2>Problems with $a[RPC]</h2>
<p>
	The first issue with $a[RPC] is that it must cache results on the server side in case they don&apos;t make it to the client.
	If the results make it, but the acknowledgement doesn&apos;t make it back to the server, the server may end up resending the results thinking the client never got them.
	If the client is no longer listening to for the reply, as it&apos;s already received it, this could lead to the server retransmitting repeatedly and will likely result in the results being cached indefinitely.
	This was such a big problem that Sun Microsystems went and developed an alternative version of $a[RPC] to get around the problem (Dordal, 2014).
</p>
<p>
	Another problem is $a[RPC] has no sense of sessions; it only has a single request, a single reply, and a single acknowledgement.
	While this is in fact it&apos;s strength, it&apos;s a big weakness as well.
	It means that neither the request nor the reply can exceed the limits of a single packet in length.
	For some applications, such as $a[DNS], this is perfectly acceptable.
	That&apos;s more than enough space to get the job done.
	For other applications though, it makes $a[RPC] an invalid choice of transfer protocols.
	Imagine trying to download a live disk image for your favourite Linux distribution.
	With so much software and other data packed into it, the file size would exceed the limits of a single packet, probably by over a million fold.
	$a[RPC] simply can&apos;t handle that type of usage.
	Transfer of files, including multi-packet files, has been implemented.
	However, it&apos;s done by breaking the file into pieces and having the client request not the file, but a <strong>*specific chunk*</strong> of the file.
	Some types of long requests or replies can be broken down in a sensible way such as this, but not all can.
	Even for fragmented file transfer such as this, it doesn&apos;t allow for disk-level optimisations to be made, as each segment is transferred individually, and not within the context of the file as a whole.
</p>
<p>
	Lastly, $a[RPC] doesn&apos;t handle network congestion well.
	As a result, it works fine over a single $a[LAN] and in a few other cases, but it for the most part doesn&apos;t function well over the greater Internet.
	That said, this problem hasn&apos;t stopped people from finding uses for it&apos;s use over the Internet.
	$a[DNS], one of the most widely-used Internet services, even by people that have never even heard of $a[DNS], is built on top of $a[RPC].
</p>
<h2>Timestamping</h2>
<p>
	Timestamping is used by real-time applications so the receiver of the timestamped packet can determine the current relevancy of said packet.
	As the book says (Dordal, 2014), a packet that arrives late to a real-time application is the same as a packet that never arrived.
	There&apos;s a very short window in which the packet can be used, and data loss (such as would be caused by dropping the late-arriving packet) is more tolerable than late use of the packet&apos;s payload.
</p>
<h2>$a[UDP] versus raw $a[IP] packets</h2>
<p>
	The main reason $a[UDP] should be preferred over crafting raw $a[IP] packets is the use of ports.
	If we were to build a hypothetical protocol which used raw $a[IP] packets as its mode of communication, that protocol would tie up the machine&apos;s entire line.
	$a[TCP] wouldn&apos;t get through.
	$a[UDP] wouldn&apos;t get through.
	Only one application could listen to incoming traffic, and that application would be getting <strong>*all*</strong> the traffic, trying to make sense of it.
	$a[TCP] and $a[UDP] both include the concept of ports though.
	The operating system (or a process controlled by it) then acts as the single application able to listen on the line, intercepting all packets.
	From there, the $a[OS] is able to determine which application (if any) should receive each packet based on whether $a[TCP] or $a[UDP] was used, and what port the packet was sent to.
	Without this concept of ports, network communication becomes limited to only one process, so raw $a[IP] should never be used by userland applications.
</p>
<h2>Cutting out round-trip delays</h2>
<p>
	The book doesn&apos;t seem to cover this question, but how does $a[QUIC] eliminate round trips and save time on $a[TLS] handshakes?
	It turns out that $a[QUIC] is able to make use of pre-shared keys for encryption (Thompson &amp; Hamilton, 2016).
	The first time $a[QUIC] is used to connect to a given server, no round trips can be eliminated.
	Everything must be done similarly to how it&apos;s done with $a[TLS] over $a[TCP].
	However, when a $a[TLS] connection is torn down, the $a[TLS] connection is torn down with it.
	In $a[QUIC], this is not the case, and future communications with that server may use the same keys obtained during the first connection, so round trips are saved because the handshake doesn&apos;t need to be performed this time.
</p>
<div class="APA_references">
	<h2>References:</h2>
	<p>
		Dordal, P. (2014). 11 UDP Transport - An Introduction to Computer Networks, edition 1.9.10. Retrieved from <a href="https://intronetworks.cs.luc.edu/current/html/udp.html"><code>https://intronetworks.cs.luc.edu/current/html/udp.html</code></a>
	</p>
	<p>
		Information Sciences Institute. (1981, September). RFC 791 - Internet Protocol. Retrieved from <a href="https://tools.ietf.org/html/rfc791#page-8"><code>https://tools.ietf.org/html/rfc791#page-8</code></a>
	</p>
	<p>
		Thompson, M., &amp; Hamilton, R. (2016, October 25). 2.1. Handshake Overview. Retrieved from <a href="https://tools.ietf.org/id/draft-thomson-quic-tls-01.html#rfc.section.2.1"><code>https://tools.ietf.org/id/draft-thomson-quic-tls-01.html#rfc.section.2.1</code></a>
	</p>
</div>
END
);
